This is meant to replace #41 , by actually implementing the support within pppd instead of as a script

I forgot to mention that I could test this on Linux, but not on Solaris: I haven't managed to install a Solaris KVM VM, it would either not manage to drive the network board (including several models), or would just hang/crash/reboot.

👍 defaultroute6 would be a handy option.

It's more than handy, it seems to me to be pretty much essential. If there's some good reason why we shouldn't have it, or why it's a bad idea, it would be most helpful to understand!

I was thinking more about this option and I'm not sure if such option is needed at all.

Routing configuration in IPv6 is setting differently as in IPv4.

In IPv4 is default gateway (=router address) assigned by DHCP server or when using PPP it is expected that "other side" of PPP tunnel has connection to internet and can route any traffic to it. This is enabled by "defaultroute" option. DHCP is not used over PPP.

But in IPv6 default gateway is not assigned by DHCPv6 protocol (there is even no option for it!) but rather by ICMPv6 Router Advertisement packets which are periodically sent by every router in network. Machine on the network therefore can see more then one IPv6 router and based on priorities/metrics can decide which IPv6 router would use. When using PPP its IPV6CP protocol exchange only IPv6 link local addresses. No IPv6 globally routable addresses and also no IPv6 router (as opposite of the IPv4 where PPP's IPCP protocol exchange real IPv4 address which can be used to access internet, either public or via NAT). Therefore IPv6 addresses exchanged by PPP's IPV6CP protocol cannot be even used for routing. Linux kernel disallow to send packets from IPv6 link local address to some globally address.

In IPv6 also over PPP is used also ICMPv6 Router Advertisement packet and DHCPv6 protcol for assigning globally routable IPv6 address and therefore also routing information (like default gateway=router via ICMPv6 Router Advertisement). This is opposite of the IPv4 over PPP where DHCP is not used and PPP's IPCP exchange all information. Here for IPv6 PPP exchange only the minimum (=link local addresses) and let everything else for other protocols which are used over ethernet (or any other media), to have common setup of IPv6 over any transport layer.

Note that on Linux, kernel automatically performs stateless autoconfiguration of IPv6 addresses from ICMPv6 Router Advertisement packets sent by peer/other side. And part of it is also autoconfiguration of routing.

So I think this option defaultroute6 in this pull request should not be used at all and I think it can be useful only for broken internet setups or when all IPv6 addresses and routing is done manually, meaning that manual static configuration is used.

It means that defaultroute6 is not IPv6 equivalent to the defaultroute option. In IPv4 word defaultroute option is basically required for PPP to have working internet connection. In IPv6 work this defaultroute6 is not required for PPP to have working connection and when proper setup via ICMPv6 Router Advertisement is used, it may moreover cause issues.

I think that this should be also described in manual page / documentation, so people or pppd distribution would not enable defaultroute6 option by default. It needs to be used with caution (=I know what I'm doing, I understand how IPv6 is working and for my special case I really need it).

@paulusmack: What do you think about it?

It means that defaultroute6 is not IPv6 equivalent to the defaultroute option. In IPv4 word defaultroute option is basically required for PPP to have working internet connection. In IPv6 work this defaultroute6 is not required for PPP to have working connection and when proper setup via ICMPv6 Router Advertisement is used, it may moreover cause issues.

Sure!

so people or pppd distribution would not enable defaultroute6 option by default.

Why would they?

I mean, either people want to set up IPv6 the same way the set up IPv4, out of lazyness, which is completely understandable, and the defaultroute6 is helpful here and matches what they would look for. Or they want to do it "the ipv6 way", and they don't have to do anything particular to get it.

I don't see the point of making the documentation more lengthy only to "promote" "the ipv6 way". We can only make IPv6 a real thing if people are not made scared of it.

It needs to be used with caution (=I know what I'm doing, I understand how IPv6 is working and for my special case I really need it).

I believe the converse: "I have a working IPv4 set up and for now I just want to do IPv6 the same way, I'll have a look at “the proper IPv6 way” later if I find it useful".

Problem is that IPv6 does not work in the same way as IPv4. I do not know what is common setup over the world, but what I see around me is that ISPs uses ICMPv6 Router Advertisement and DHCPv6 prefix delegation for assiging IPv6 addresses (and whole prefix) to end users. They do not use "same way as IPv4" (because it does not make sense...). If you want to have IPv6 connection to internet, you have to configure it as ISP expects. Not as user may want (= same as IPv4). Incorrect configuration means no IPv6 access...

And as I explained above you cannot set "IPv6 the same way the set up IPv4" over PPP. Just because PPP's IPV6CP does not support negotiation of globally routable IPv6 addresses. As I wrote above Linux kernel do not allow you to use PPP's negotiated IPv6 link local address for acessing IPv6 internet. So idea "IPv6 the same way the set up IPv4" may cause issues if you really do not know how it is working and "for lazyness" it means that you do not have time to think about it more.

Problem is that IPv6 does not work in the same way as IPv4. I do not know what is common setup over the world, but what I see around me is that ISPs uses ICMPv6 Router Advertisement and DHCPv6 prefix delegation for assiging IPv6 addresses (and whole prefix) to end users.

Then it'll just work already, and users won't even think about adding defaultroute6.

But for a manually set up ppp link, that used to be set up only for IPv4, it can make sense to set it up in IPv6 just like it was in IPv4, I don't see the point of introducing FUD here.

But for a manually set up ppp link, that used to be set up only for IPv4, it can make sense to set it up in IPv6 just like it was in IPv4, I don't see the point of introducing FUD here.

In specific conditions it make sense. But I was doing now different IPv6 tests (see #111) and I still have not figured out what is the example or common situation when you want such setup. As I explained above "set it up in IPv6 just like it was in IPv4" cannot be done for PPP due to missing option how to exchange routable IPv6 address. Also pppd does not support setting manual routable IPv6 address (it is supported by pppd only for IPv4 addresses), so if you want to use such setup, you have to first start pppd, then manually assign your routable IPv6 addresses to ppp0 interface and then setup correct routes for these your manually assigned IPv6 addresses. And after this step you do not need default route set by pppd's defaultroute6 option.

What I'm trying to show is that blindly thinking "I set these similar IPv6 options as in IPv4" would not work as expected. And therefore I think it should be documented in manpage. So people who want to setup manually ppp link with IPv6 support can read what additional steps are needed to have it working as defaultroute6 is not enough as somebody may thing...

I still think that description "how it works" and "what these options are really doing with network setup" and "what else is needed to enable/disable to prevent problems" can be useful.

Anyway, this defaultroute6 option may be useful once pppd daemon gets support for assigning/specifying routable IPv6 address on local interface. Then it can be compared to IPv4 connection. As pppd will be able to set route and also address (like in IPv4). This looks like a nice "feature request".

I asked for this a year and a half ago, and at that time, it would have been very useful, as my ISP did not properly handle the negotiation phase for IPv6. I ended up having to add an /etc/ppp/ipv6-up.local whose sole function was to do /sbin/ip -6 route add default dev ppp0. An ipv6defaultroute option would have been most useful, and frankly, remains so.

I agree that if the option is added, it shouldn't be the default, because pali's right: it's not needed when the ISP is doing things properly. When they're not, however, it would be most helpful if it were available; and I suspect some ISPs will continue to do IPv6 wrong.

Thank you for this information! It is really important to know that such ISP really exist. Could you share name of ISP and in which country is? I think this could help other people how to connect to IPv6 via this ISP.

I would like to know how this ISP negotiated IPv6 address? Have you done some manual static assignment via script? Or somehow via DHCPv6?

It's the UK; because, in the main, my ISP has been very good, I'm not going to name them here. The arrangement is that I have a /56 assigned to me, which I then chose to split into various /64s, each of which is statically assigned to one of the VLANs hanging off the interior NIC of my firewall. The exterior NIC acquires a link-local IPv6 address via pppd (over Ethernet):

Dec  9 21:21:03 titus pppd[27194]: local  LL address fe80::0000:0000:0000:0001
Dec  9 21:21:03 titus pppd[27194]: remote LL address fe80::d2f0:dbff:fe6c:e000

My ISP routes all the traffic for my /56 to me via my exterior link-local address; I had to manually add a default route back to them.

Ok! link-local addresses are irrelevant here as they cannot be used for internet access (they can be used only for contacting other end of tunnel, not for routing).

I mean how you get negotiated /54 prefix of globally routable IPv6 addresses via PPP?

I know the link-local address is irrelevant for global communications, I show it so you know what, if anything, pppd negotiates by way of v6 addressing. The globally-routable /56 was assigned to me by the ISP and communicated by email. I did say it was statically-assigned to the interfaces it's on, you may recall.

Thank you for explanation! Now I see how it worked. PPP exchanged link local addresses and all routing and global addresses was up to the user/customer to set it up manually without any PPP interaction. So you had to also set routing table have access to internet and this pppd's option defaultroute6 do it for you. And global IPv6 addresses you still had to setup manually (as pppd was not able to do it). This is one of the way when defaultroute6 is useful.

This is one of the way when defaultroute6 is useful.

Yes, I rather thought so; I'm glad you concur.

There is also many providers not doing router advertisements on PPP interfaces or they only allow to explicitly solicit them.

Basically this option provided here is great and solves many problems:

• some providers only respond to router solicitation and send unicast router advertisement in response. This helps to let the kernel setup link, but if they don't send further multicast advertisements, the route gets lost after 30 minutes (default lifetime). Many people see this all the time with "broken providers". Actually as the route never changes for a given PPP connection it makes no sense to have a lifetime. So defining it statically and disabling RA support is a good idea (see below).
• many setups disable accepting router advertisement on routing interfaces (e.g,, static ones, or if IP forwarding is enabled; of course the PPP interfaces has forwarding enabled is most consumer router setups). Without the option here it is not easy to define a route through the PPP connection if you do not know the remote end. Luckily as it is a point to point interface, the kernel knows the other end so adding the route without a link local target works (you only need the ip -6 add route default dev pppX). If you think more about it, actually providers not sending router advertisements are not doing something really wrong, because the remote endpoint of a peer to peer interface is in reality always the router to be used (as it is point to point). Most consumer routers handle it exactly like this. And therefore many providers no longer send RAs by default (there are other reasons why they don't send them, it is too much info for this issue...).

So in short: point to point tunnels should setup routes on setup once without life time using the pair of link local addresses. This is what this option does.

For setting up public ipv6 addresses, later it uses prefix delegation or static setup. The routing is separated from that.